WebGL uniformų buferio objektai: efektyvus šešėliavimo programų duomenų perdavimas

Dinamiškame interneto 3D grafikos pasaulyje našumas yra svarbiausias. Kadangi WebGL programos tampa vis sudėtingesnės, efektyvus didelių duomenų kiekių tvarkymas šešėliavimo programoms (shaders) yra nuolatinis iššūkis. Kūrėjams, orientuotiems į WebGL2 (kuris atitinka OpenGL ES 3.0), uniformų buferio objektai (UBO) siūlo galingą šios problemos sprendimą. Šis išsamus vadovas gilinsis į UBO, paaiškins jų būtinybę, veikimo principą ir kaip išnaudoti visą jų potencialą kuriant didelio našumo, vizualiai stulbinančias WebGL patirtis pasaulinei auditorijai.

Nesvarbu, ar kuriate sudėtingą duomenų vizualizaciją, įtraukiantį žaidimą ar pažangiausią papildytos realybės patirtį, UBO supratimas yra labai svarbus norint optimizuoti atvaizdavimo konvejerį ir užtikrinti, kad jūsų programos sklandžiai veiktų įvairiuose įrenginiuose ir platformose visame pasaulyje.

Įvadas: šešėliavimo programų duomenų valdymo evoliucija

Prieš gilinantis į UBO specifiką, būtina suprasti šešėliavimo programų duomenų valdymo aplinką ir kodėl UBO reiškia tokį reikšmingą žingsnį į priekį. WebGL, šešėliavimo programos (shaders) yra mažos programos, veikiančios grafikos apdorojimo bloke (GPU) ir nurodančios, kaip atvaizduojami jūsų 3D modeliai. Kad atliktų savo užduotis, šioms šešėliavimo programoms dažnai reikia išorinių duomenų, vadinamų „uniforms“.

„Uniforms“ iššūkiai WebGL1/OpenGL ES 2.0 versijose

Originalioje WebGL versijoje (paremtoje OpenGL ES 2.0), uniform kintamieji buvo valdomi individualiai. Kiekvienas uniform kintamasis šešėliavimo programoje turėjo būti identifikuotas pagal jo vietą (naudojant gl.getUniformLocation) ir tada atnaujinamas naudojant specifines funkcijas, tokias kaip gl.uniform1f, gl.uniformMatrix4fv ir pan. Šis metodas, nors ir paprastas nesudėtingoms scenoms, kėlė keletą iššūkių, kai programos tapdavo sudėtingesnės:

• Didelės CPU sąnaudos: Kiekvienas gl.uniform... iškvietimas apima konteksto perjungimą tarp centrinio procesoriaus (CPU) ir GPU, o tai gali būti skaičiavimo požiūriu brangu. Scenose su daugeliu objektų, kurių kiekvienam reikia unikalių uniform duomenų (pvz., skirtingų transformacijos matricų, spalvų ar medžiagos savybių), šie iškvietimai greitai kaupiasi ir tampa reikšmingu našumo butelio kakleliu. Šios sąnaudos ypač pastebimos mažesnio našumo įrenginiuose arba scenarijuose su daugeliu skirtingų atvaizdavimo būsenų.
• Perteklinis duomenų perdavimas: Jei kelios šešėliavimo programos dalijosi bendrais uniform duomenimis (pvz., projekcijos ir vaizdo matricomis, kurios yra pastovios kameros pozicijai), tie duomenys turėjo būti siunčiami į GPU atskirai kiekvienai programai. Tai lėmė neefektyvų atminties naudojimą ir nereikalingą duomenų perdavimą, švaistant brangų pralaidumą.
• Ribota uniform kintamųjų saugykla: WebGL1 turi gana griežtus apribojimus individualių uniform kintamųjų, kuriuos gali deklaruoti šešėliavimo programa, skaičiui. Šis apribojimas gali greitai tapti ribojančiu sudėtingiems šešėliavimo modeliams, reikalaujantiems daug parametrų, pavyzdžiui, fiziškai pagrįsto atvaizdavimo (PBR) medžiagoms su daugybe tekstūrų žemėlapių ir medžiagų savybių.
• Prastos grupavimo galimybės: Uniform kintamųjų atnaujinimas kiekvienam objektui atskirai apsunkina efektyvų piešimo iškvietimų grupavimą (batching). Grupavimas yra kritinė optimizavimo technika, kai keli objektai atvaizduojami vienu piešimo iškvietimu, sumažinant API sąnaudas. Kai uniform duomenys turi keistis kiekvienam objektui, grupavimas dažnai yra nutraukiamas, o tai daro įtaką atvaizdavimo našumui, ypač siekiant didelio kadrų dažnio įvairiuose įrenginiuose.

Šie apribojimai apsunkino WebGL1 programų mastelio didinimą, ypač tų, kurios siekė didelio vizualinio tikslumo ir sudėtingo scenos valdymo, neaukojant našumo. Kūrėjai dažnai griebdavosi įvairių sprendimo būdų, pavyzdžiui, pakuodami duomenis į tekstūras arba rankiniu būdu permaišydami atributų duomenis, tačiau šie sprendimai pridėjo sudėtingumo ir ne visada buvo optimalūs ar universaliai taikomi.

Pristatome WebGL2 ir UBO galią

Atsiradus WebGL2, kuris į internetą atneša OpenGL ES 3.0 galimybes, atsirado nauja uniform kintamųjų valdymo paradigma: uniformų buferio objektai (UBO). UBO iš esmės keičia, kaip tvarkomi uniform duomenys, leisdami kūrėjams grupuoti kelis uniform kintamuosius į vieną buferio objektą. Šis buferis tada saugomas GPU ir gali būti efektyviai atnaujinamas bei pasiekiamas vienos ar kelių šešėliavimo programų.

UBO įvedimas tiesiogiai sprendžia minėtas problemas, suteikdamas tvirtą ir efektyvų mechanizmą dideliems, struktūrizuotiems duomenų rinkiniams perduoti į šešėliavimo programas. Jie yra modernių, didelio našumo WebGL2 programų pagrindas, siūlantis kelią į švaresnį kodą, geresnį išteklių valdymą ir galiausiai sklandesnę vartotojo patirtį. Bet kuriam kūrėjui, norinčiam peržengti 3D grafikos naršyklėje ribas, UBO yra esminė koncepcija, kurią reikia įvaldyti.

Kas yra uniformų buferio objektai (UBO)?

Uniformų buferio objektas (UBO) yra specializuotas buferio tipas WebGL2, skirtas saugoti uniform kintamųjų rinkinius. Vietoj to, kad siųstumėte kiekvieną uniform kintamąjį individualiai, jūs juos supakuojate į vieną duomenų bloką, įkeliate šį bloką į GPU buferį, o tada pririšate tą buferį prie savo šešėliavimo programos (-ų). Galvokite apie tai kaip apie skirtą atminties sritį GPU, kurioje jūsų šešėliavimo programos gali efektyviai ieškoti duomenų, panašiai kaip atributų buferiai saugo viršūnių duomenis.

Pagrindinė idėja yra sumažinti atskirų API iškvietimų skaičių uniform kintamiesiems atnaujinti. Sujungdami susijusius uniform kintamuosius į vieną buferį, jūs konsoliduojate daug mažų duomenų perdavimų į vieną didesnę, efektyvesnę operaciją.

Pagrindinės koncepcijos ir privalumai

Suprasti pagrindinius UBO privalumus yra labai svarbu norint įvertinti jų poveikį jūsų WebGL projektams:

• Sumažintos CPU-GPU sąnaudos: Tai bene didžiausias privalumas. Vietoj dešimčių ar šimtų individualių gl.uniform... iškvietimų per kadrą, dabar galite atnaujinti didelę uniform kintamųjų grupę vienu gl.bufferData ar gl.bufferSubData iškvietimu. Tai drastiškai sumažina komunikacijos sąnaudas tarp CPU ir GPU, atlaisvinant CPU ciklus kitoms užduotims (pvz., žaidimo logikai, fizikai ar UI atnaujinimams) ir gerinant bendrą atvaizdavimo našumą. Tai ypač naudinga įrenginiuose, kur CPU-GPU komunikacija yra butelio kaklelis, kas yra įprasta mobiliose aplinkose ar integruotuose grafikos sprendimuose.
• Grupavimo ir pavyzdžių atvaizdavimo efektyvumas: UBO labai palengvina pažangias atvaizdavimo technikas, tokias kaip pavyzdžių atvaizdavimas (instanced rendering). Galite saugoti pavyzdžio duomenis (pvz., modelio matricas, spalvas) ribotam pavyzdžių skaičiui tiesiogiai UBO. Derindami UBO su gl.drawArraysInstanced ar gl.drawElementsInstanced, vienas piešimo iškvietimas gali atvaizduoti tūkstančius pavyzdžių su skirtingomis savybėmis, tuo pačiu efektyviai pasiekdamas jų unikalius duomenis per UBO, naudojant gl_InstanceID šešėliavimo programos kintamąjį. Tai yra proveržis scenoms su daugeliu identiškų ar panašių objektų, pavyzdžiui, minios, miškai ar dalelių sistemos.
• Nuoseklūs duomenys tarp šešėliavimo programų: UBO leidžia apibrėžti uniform kintamųjų bloką šešėliavimo programoje, o tada dalytis tuo pačiu UBO buferiu tarp kelių skirtingų šešėliavimo programų. Pavyzdžiui, jūsų projekcijos ir vaizdo matricos, kurios apibrėžia kameros perspektyvą, gali būti saugomos viename UBO ir prieinamos visoms jūsų šešėliavimo programoms (nepermatomiems objektams, permatomiems objektams, post-apdorojimo efektams ir t. t.). Tai užtikrina duomenų nuoseklumą (visos šešėliavimo programos mato tą patį kameros vaizdą), supaprastina kodą centralizuojant kameros valdymą ir sumažina perteklinį duomenų perdavimą.
• Atminties efektyvumas: Pakuodami susijusius uniform kintamuosius į vieną buferį, UBO kartais gali lemti efektyvesnį atminties naudojimą GPU, ypač kai keli maži uniform kintamieji kitaip sukeltų sąnaudas kiekvienam kintamajam. Be to, UBO bendrinimas tarp programų reiškia, kad duomenys GPU atmintyje turi būti tik vieną kartą, o ne dubliuojami kiekvienai juos naudojančiai programai. Tai gali būti labai svarbu atminties apribotose aplinkose, pavyzdžiui, mobiliosiose naršyklėse.
• Padidinta uniform kintamųjų saugykla: UBO suteikia būdą apeiti individualių uniform kintamųjų skaičiaus apribojimus WebGL1. Bendras uniform bloko dydis paprastai yra daug didesnis nei maksimalus individualių uniform kintamųjų skaičius, leidžiantis sudėtingesnes duomenų struktūras ir medžiagų savybes jūsų šešėliavimo programose, nepasiekiant aparatinės įrangos apribojimų. WebGL2 gl.MAX_UNIFORM_BLOCK_SIZE dažnai leidžia saugoti kilobaitus duomenų, gerokai viršijant individualių uniform kintamųjų apribojimus.

UBO prieš standartinius „Uniforms“

Štai greitas palyginimas, siekiant pabrėžti esminius skirtumus ir kada naudoti kiekvieną metodą:

Svarbu pažymėti, kad UBO visiškai nepakeičia standartinių uniform kintamųjų. Dažnai naudosite abiejų derinį: UBO globaliai bendrinamiems arba dažnai atnaujinamiems dideliems duomenų blokams, o standartinius uniform kintamuosius – duomenims, kurie yra tikrai unikalūs konkrečiam piešimo iškvietimui ar objektui ir nereikalauja UBO sąnaudų.

Gilinamės: kaip veikia UBO

Norint efektyviai įgyvendinti UBO, reikia suprasti pagrindinius mechanizmus, ypač pririšimo taškų sistemą ir kritines duomenų išdėstymo taisykles.

Pririšimo taškų sistema

UBO funkcionalumo pagrindas yra lanksti pririšimo taškų sistema. GPU palaiko indeksuotų „pririšimo taškų“ (taip pat vadinamų „pririšimo indeksais“ arba „uniform buferio pririšimo taškais“) rinkinį, kurių kiekvienas gali laikyti nuorodą į UBO. Šie pririšimo taškai veikia kaip universalūs lizdai, į kuriuos galima prijungti jūsų UBO.

Kaip kūrėjas, jūs esate atsakingas už aiškų trijų žingsnių procesą, kad sujungtumėte savo duomenis su šešėliavimo programomis:

1. Sukurkite ir užpildykite UBO: Jūs skiriate buferio objektą GPU (gl.createBuffer()) ir užpildote jį savo uniform duomenimis iš CPU (gl.bufferData() arba gl.bufferSubData()). Šis UBO yra tiesiog atminties blokas, laikantis neapdorotus duomenis.
2. Pririškite UBO prie globalaus pririšimo taško: Jūs susiejate savo sukurtą UBO su konkrečiu skaitiniu pririšimo tašku (pvz., 0, 1, 2 ir t. t.) naudodami gl.bindBufferBase(gl.UNIFORM_BUFFER, bindingPointIndex, uboObject) arba gl.bindBufferRange() daliniam pririšimui. Tai padaro UBO globaliai pasiekiamą per tą pririšimo tašką.
3. Sujunkite šešėliavimo programos uniform bloką su pririšimo tašku: Savo šešėliavimo programoje deklaruojate uniform bloką, o tada, JavaScript'e, susiejate tą konkretų uniform bloką (identifikuotą pagal jo pavadinimą šešėliavimo programoje) su tuo pačiu skaitiniu pririšimo tašku naudodami gl.uniformBlockBinding(shaderProgram, uniformBlockIndex, bindingPointIndex).

Šis atskyrimas yra galingas: *šešėliavimo programa* tiesiogiai nežino, kurį konkretų UBO ji naudoja; ji tik žino, kad jai reikia duomenų iš „pririšimo taško X“. Tada galite dinamiškai keisti UBO (ar net UBO dalis), priskirtus pririšimo taškui X, neperkompiliuodami ar neperjungdami šešėliavimo programų, o tai suteikia didžiulį lankstumą dinamiškiems scenos atnaujinimams ar daugiapakopiam atvaizdavimui. Galimų pririšimo taškų skaičius paprastai yra ribotas, bet pakankamas daugumai programų (užklauskite gl.MAX_UNIFORM_BUFFER_BINDINGS).

Standartiniai uniformų blokai

Savo GLSL (Graphics Library Shading Language) šešėliavimo programose, skirtose WebGL2, jūs deklaruojate uniform blokus naudodami raktinį žodį uniform, po kurio eina bloko pavadinimas, o tada kintamieji riestiniuose skliaustuose. Taip pat nurodote išdėstymo kvalifikatorių, dažniausiai std140, kuris nurodo, kaip duomenys yra supakuoti į buferį. Šis išdėstymo kvalifikatorius yra absoliučiai kritiškas, norint užtikrinti, kad jūsų JavaScript pusės duomenys atitiktų GPU lūkesčius.

            #version 300 es

layout (std140) uniform CameraMatrices {
    mat4 projection;
    mat4 view;
    vec3 cameraPosition;
    float exposure;
} CameraData;

// ... rest of your shader code ...

            

              
                Copy
              
            
          

Šiame pavyzdyje:

• layout (std140): Tai yra išdėstymo kvalifikatorius. Jis yra labai svarbus apibrėžiant, kaip uniform bloko nariai yra išlygiuoti ir išdėstyti atmintyje. WebGL2 reikalauja palaikyti std140. Kiti išdėstymai, tokie kaip shared ar packed, egzistuoja stalinių kompiuterių OpenGL, bet nėra garantuoti WebGL2/ES 3.0.
• uniform CameraMatrices: Tai deklaruoja uniform bloką, pavadintą CameraMatrices. Tai yra eilutės pavadinimas, kurį naudosite JavaScript'e (su gl.getUniformBlockIndex), kad identifikuotumėte bloką šešėliavimo programoje.
• mat4 projection;, mat4 view;, vec3 cameraPosition;, float exposure;: Tai yra uniform kintamieji, esantys bloke. Jie veikia kaip įprasti uniform kintamieji šešėliavimo programoje, bet jų duomenų šaltinis yra UBO.
• } CameraData;: Tai yra neprivalomas *pavyzdžio pavadinimas* uniform blokui. Jei jį praleisite, bloko pavadinimas (CameraMatrices) veiks ir kaip bloko pavadinimas, ir kaip pavyzdžio pavadinimas. Paprastai yra gera praktika nurodyti pavyzdžio pavadinimą aiškumui ir nuoseklumui, ypač kai galite turėti kelis to paties tipo blokus. Pavyzdžio pavadinimas naudojamas prieigai prie narių šešėliavimo programoje (pvz., CameraData.projection).

Duomenų išdėstymo ir išlygiavimo reikalavimai

Tai bene kritiškiausias ir dažnai neteisingai suprantamas UBO aspektas. GPU reikalauja, kad duomenys buferiuose būtų išdėstyti pagal konkrečias išlygiavimo taisykles, kad būtų užtikrintas efektyvus priėjimas. WebGL2 numatytasis ir dažniausiai naudojamas išdėstymas yra std140. Jei jūsų JavaScript duomenų struktūra (pvz., Float32Array) tiksliai neatitinka std140 taisyklių dėl užpildymo (padding) ir išlygiavimo, jūsų šešėliavimo programos skaitys neteisingus ar sugadintus duomenis, o tai lems vizualinius trikdžius ar strigimus.

std140 išdėstymo taisyklės nustato kiekvieno nario išlygiavimą uniform bloke ir bendrą bloko dydį. Šios taisyklės užtikrina nuoseklumą tarp skirtingos aparatinės įrangos ir tvarkyklių, tačiau reikalauja kruopštaus rankinio skaičiavimo arba pagalbinių bibliotekų naudojimo. Štai svarbiausių taisyklių santrauka, darant prielaidą, kad bazinis skaliaro dydis (N) yra 4 baitai (float, int arba bool):

• Skaliariniai tipai (float, int, bool):
  • Bazinis išlygiavimas: N (4 baitai).
  • Dydis: N (4 baitai).
• Vektorių tipai (vec2, vec3, vec4):
  • vec2: Bazinis išlygiavimas: 2N (8 baitai). Dydis: 2N (8 baitai).
  • vec3: Bazinis išlygiavimas: 4N (16 baitų). Dydis: 3N (12 baitų). Tai labai dažnas painiavos šaltinis; vec3 yra išlygiuotas taip, lyg būtų vec4, bet užima tik 12 baitų. Todėl jis visada prasidės nuo 16 baitų ribos.
  • vec4: Bazinis išlygiavimas: 4N (16 baitų). Dydis: 4N (16 baitų).
• Masyvai:
  • Kiekvienas masyvo elementas (nepriklausomai nuo jo tipo, net ir vienas float) yra išlygiuotas pagal vec4 bazinį išlygiavimą (16 baitų) arba savo bazinį išlygiavimą, priklausomai nuo to, kuris yra didesnis. Praktiniais tikslais, tarkime, kad kiekvienas masyvo elementas yra išlygiuotas 16 baitų.
  • Pavyzdžiui, float masyve (float[]) kiekvienas float elementas užims 4 baitus, bet bus išlygiuotas 16 baitų. Tai reiškia, kad po kiekvieno float masyve bus 12 baitų užpildymo.
  • Žingsnis (atstumas tarp vieno elemento pradžios ir kito pradžios) yra apvalinamas iki 16 baitų kartotinio.
• Struktūros (struct):
  • Struktūros bazinis išlygiavimas yra didžiausias bet kurio jos nario bazinis išlygiavimas, suapvalintas iki 16 baitų kartotinio.
  • Kiekvienas narys struktūroje laikosi savo išlygiavimo taisyklių, palyginti su struktūros pradžia.
  • Bendras struktūros dydis (nuo jos pradžios iki paskutinio nario pabaigos) yra suapvalintas iki 16 baitų kartotinio. Tam gali prireikti užpildymo struktūros pabaigoje.
• Matricos:
  • Matricos traktuojamos kaip vektorių masyvai. Kiekvienas matricos stulpelis (kuris yra vektorius) laikosi masyvo elementų taisyklių.
  • mat4 (4x4 matrica) yra keturių vec4 vektorių masyvas. Kiekvienas vec4 yra išlygiuotas 16 baitų. Bendras dydis: 4 * 16 = 64 baitai.
  • mat3 (3x3 matrica) yra trijų vec3 vektorių masyvas. Kiekvienas vec3 yra išlygiuotas 16 baitų. Bendras dydis: 3 * 16 = 48 baitai.
  • mat2 (2x2 matrica) yra dviejų vec2 vektorių masyvas. Kiekvienas vec2 yra išlygiuotas 8 baitų, bet kadangi masyvo elementai yra išlygiuoti 16, kiekvienas stulpelis faktiškai prasidės nuo 16 baitų ribos. Bendras dydis: 2 * 16 = 32 baitai.

Praktinės pasekmės struktūroms ir masyvams

Iliustruokime pavyzdžiu. Apsvarstykite šį šešėliavimo programos uniform bloką:

            layout (std140) uniform LightInfo {
    vec3 lightPosition;
    float lightIntensity;
    vec4 lightColor;
    mat4 lightTransform;
    float attenuationFactors[3];
} LightData;

            

              
                Copy
              
            
          

Štai kaip tai būtų išdėstyta atmintyje, baitais (darant prielaidą, kad vienas float yra 4 baitai):

• Poslinkis 0: vec3 lightPosition;
  • Prasideda nuo 16 baitų ribos (0 yra tinkamas).
  • Užima 12 baitų (3 floats * 4 bytes/float).
  • Efektyvus dydis išlygiavimui: 16 baitų.
• Poslinkis 16: float lightIntensity;
  • Prasideda nuo 4 baitų ribos. Kadangi lightPosition efektyviai sunaudojo 16 baitų, lightIntensity prasideda nuo 16 baito.
  • Užima 4 baitus.
• Poslinkis 20-31: 12 baitų užpildymo. Tai reikalinga, kad kitas narys (vec4) atitiktų reikalaujamą 16 baitų išlygiavimą.
• Poslinkis 32: vec4 lightColor;
  • Prasideda nuo 16 baitų ribos (32 yra tinkamas).
  • Užima 16 baitų (4 floats * 4 bytes/float).
• Poslinkis 48: mat4 lightTransform;
  • Prasideda nuo 16 baitų ribos (48 yra tinkamas).
  • Užima 64 baitus (4 vec4 stulpeliai * 16 baitų/stulpeliui).
• Poslinkis 112: float attenuationFactors[3]; (trijų float'ų masyvas)
  • Kiekvienas elementas turi būti išlygiuotas 16 baitų.
  • attenuationFactors[0]: Prasideda nuo 112. Užima 4 baitus, efektyviai sunaudoja 16 baitų.
  • attenuationFactors[1]: Prasideda nuo 128 (112 + 16). Užima 4 baitus, efektyviai sunaudoja 16 baitų.
  • attenuationFactors[2]: Prasideda nuo 144 (128 + 16). Užima 4 baitus, efektyviai sunaudoja 16 baitų.
• Poslinkis 160: Bloko pabaiga. Bendras LightInfo bloko dydis būtų 160 baitų.

Tada sukurtumėte JavaScript Float32Array (arba panašų tipizuotą masyvą) tiksliai tokio dydžio (160 baitų / 4 baitai per float = 40 float'ų) ir atsargiai jį užpildytumėte, užtikrindami teisingą užpildymą, palikdami tarpus masyve. Įrankiai ir bibliotekos (pvz., WebGL specifinės pagalbinės bibliotekos) dažnai teikia pagalbą šiam procesui, tačiau kartais būtina atlikti rankinį skaičiavimą derinant ar kuriant nestandartinius išdėstymus. Netikslus skaičiavimas čia yra labai dažnas klaidų šaltinis!

UBO įgyvendinimas WebGL2: žingsnis po žingsnio vadovas

Panagrinėkime praktinį UBO įgyvendinimą. Naudosime įprastą scenarijų: saugosime kameros projekcijos ir vaizdo matricas UBO, kad galėtume jomis dalytis tarp kelių šešėliavimo programų scenoje.

Deklaracija šešėliavimo programos pusėje

Pirmiausia, apibrėžkite savo uniform bloką tiek viršūnių, tiek fragmentų šešėliavimo programose (arba ten, kur šie uniform kintamieji reikalingi). Nepamirškite #version 300 es direktyvos WebGL2 šešėliavimo programoms.

Viršūnių šešėliavimo programos pavyzdys (shader.vert)

            #version 300 es

layout (location = 0) in vec4 a_position;
layout (location = 1) in vec3 a_normal;

uniform mat4 u_modelMatrix; // This is a standard uniform, typically unique per object

// Declare the Uniform Buffer Object block
layout (std140) uniform CameraMatrices {
    mat4 projection;
    mat4 view;
    vec3 cameraPosition; // Adding camera position for completeness
    float _padding;      // Padding to align to 16 bytes after vec3
} CameraData;

out vec3 v_normal;
out vec3 v_worldPosition;

void main() {
    vec4 worldPosition = u_modelMatrix * a_position;
    gl_Position = CameraData.projection * CameraData.view * worldPosition;
    v_normal = mat3(u_modelMatrix) * a_normal;
    v_worldPosition = worldPosition.xyz;
}

            

              
                Copy
              
            
          

Čia CameraData.projection ir CameraData.view yra pasiekiami iš uniform bloko. Atkreipkite dėmesį, kad u_modelMatrix vis dar yra standartinis uniform; UBO geriausiai tinka bendrinamiems duomenų rinkiniams, o individualūs objekto uniform kintamieji (arba pavyzdžio atributai) vis dar yra įprasti savybėms, kurios yra unikalios kiekvienam objektui.

Pastaba dėl _padding: vec3 (12 baitų), po kurio eina float (4 baitai), paprastai susipakuotų glaudžiai. Tačiau, jei kitas narys būtų, pavyzdžiui, vec4 ar kita mat4, float galėtų natūraliai neišsilygiuoti pagal 16 baitų ribą std140 išdėstyme, sukeldamas problemų. Aiškus užpildymas (float _padding;) kartais pridedamas aiškumui arba norint priversti išlygiavimą. Šiuo konkrečiu atveju, vec3 yra 16 baitų išlygiuotas, float yra 4 baitų išlygiuotas, todėl cameraPosition (16 baitų) + _padding (4 baitai) puikiai užima 20 baitų. Jei po jo sektų vec4, jis turėtų prasidėti nuo 16 baitų ribos, taigi nuo 32 baito. Nuo 20 baito lieka 12 baitų užpildymo. Šis pavyzdys rodo, kad reikalingas kruopštus išdėstymas.

Fragmentų šešėliavimo programos pavyzdys (shader.frag)

Net jei fragmentų šešėliavimo programa tiesiogiai nenaudoja matricų transformacijoms, jai gali prireikti su kamera susijusių duomenų (pvz., kameros padėties atspindžio apšvietimo skaičiavimams) arba galite turėti kitą UBO medžiagų savybėms, kurias naudoja fragmentų šešėliavimo programa.

            #version 300 es

precision highp float;

in vec3 v_normal;
in vec3 v_worldPosition;

uniform vec3 u_lightDirection; // Standard uniform for simplicity
uniform vec4 u_objectColor;

// Declare the same Uniform Buffer Object block here
layout (std140) uniform CameraMatrices {
    mat4 projection;
    mat4 view;
    vec3 cameraPosition;
    float _padding; 
} CameraData;

out vec4 outColor;

void main() {
    // Basic diffuse lighting using a standard uniform for light direction
    float diffuse = max(dot(normalize(v_normal), normalize(u_lightDirection)), 0.0);
    
    // Example: Using camera position from UBO for view direction
    vec3 viewDirection = normalize(CameraData.cameraPosition - v_worldPosition);
    // For a simple demo, we'll just use diffuse for output color
    outColor = u_objectColor * diffuse;
}

            

              
                Copy
              
            
          

JavaScript pusės įgyvendinimas

Dabar pažvelkime į JavaScript kodą, skirtą šiam UBO valdyti. Naudosime populiarią gl-matrix biblioteką matricų operacijoms.

            // Assume 'gl' is your WebGL2RenderingContext, obtained from canvas.getContext('webgl2')
// Assume 'shaderProgram' is your linked WebGLProgram, obtained from createProgram(gl, vsSource, fsSource)

import { mat4, vec3 } from 'gl-matrix';

// --------------------------------------------------------------------------------
// Step 1: Create the UBO Buffer Object
// --------------------------------------------------------------------------------
const cameraUBO = gl.createBuffer();
gl.bindBuffer(gl.UNIFORM_BUFFER, cameraUBO);

// Determine the size needed for the UBO based on std140 layout:
// mat4: 16 floats (64 bytes)
// mat4: 16 floats (64 bytes)
// vec3: 3 floats (12 bytes), but aligned to 16 bytes
// float: 1 float (4 bytes)
// Total floats: 16 + 16 + 4 + 4 = 40 floats (considering padding for vec3 and float)
// In the shader: mat4 (64) + mat4 (64) + vec3 (16) + float (16) = 160 bytes
// Calculation:
// projection (mat4) = 64 bytes
// view (mat4) = 64 bytes
// cameraPosition (vec3) = 12 bytes + 4 bytes padding (to reach 16-byte boundary for next float) = 16 bytes
// exposure (float) = 4 bytes + 12 bytes padding (to end on 16-byte boundary) = 16 bytes
// Total = 64 + 64 + 16 + 16 = 160 bytes

const UBO_BYTE_SIZE = 160; 
// Allocate memory on GPU. Use DYNAMIC_DRAW as camera matrices update every frame.
gl.bufferData(gl.UNIFORM_BUFFER, UBO_BYTE_SIZE, gl.DYNAMIC_DRAW);
gl.bindBuffer(gl.UNIFORM_BUFFER, null); // Unbind the UBO from the UNIFORM_BUFFER target

// --------------------------------------------------------------------------------
// Step 2: Define and Populate CPU-Side Data for the UBO
// --------------------------------------------------------------------------------
const projectionMatrix = mat4.create(); // Use gl-matrix for matrix operations
const viewMatrix = mat4.create();
const cameraPos = vec3.fromValues(0, 0, 5); // Initial camera position
const exposureValue = 1.0; // Example exposure value

// Create a Float32Array to hold the combined data.
// This must match the std140 layout exactly. 
// Projection (16 floats), View (16 floats), CameraPosition (4 floats due to vec3+padding),
// Exposure (4 floats due to float+padding). Total: 16+16+4+4 = 40 floats.
const cameraMatricesData = new Float32Array(40); 

// ... calculate your initial projection and view matrices ...
mat4.perspective(projectionMatrix, Math.PI / 4, gl.canvas.width / gl.canvas.height, 0.1, 100.0);
mat4.lookAt(viewMatrix, cameraPos, vec3.fromValues(0, 0, 0), vec3.fromValues(0, 1, 0));

// Copy data into the Float32Array, observing std140 offsets
cameraMatricesData.set(projectionMatrix, 0);       // Offset 0 (16 floats)
cameraMatricesData.set(viewMatrix, 16);            // Offset 16 (16 floats)
cameraMatricesData.set(cameraPos, 32);             // Offset 32 (vec3, 3 floats). Next available is 32+3=35.
// There's 1 float of padding in the shader's vec3, so the next item starts at offset 36 in the Float32Array.
cameraMatricesData[35] = exposureValue;            // Offset 35 (float). This is tricky. The float 'exposure' is at byte 140.
                                                   // 160 bytes / 4 bytes per float = 40 floats.
                                                   // `projection` takes 0-15.
                                                   // `view` takes 16-31.
                                                   // `cameraPosition` takes 32, 33, 34.
                                                   // The `_padding` for `vec3 cameraPosition` is at index 35.
                                                   // `exposure` is at index 36. This is where manual tracking is vital.
// Let's re-evaluate the padding carefully for `cameraPosition` and `exposure`
// shader: mat4 projection (64 bytes)
// shader: mat4 view (64 bytes)
// shader: vec3 cameraPosition (16 bytes aligned, 12 bytes used)
// shader: float _padding (4 bytes, fills out 16 bytes for vec3)
// shader: float exposure (16 bytes aligned, 4 bytes used)
// Total 64+64+16+16 = 160 bytes

// Float32Array Indices:
// projection: indices 0-15
// view: indices 16-31
// cameraPosition: indices 32-34 (3 floats for vec3)
// padding after cameraPosition: index 35 (1 float for the _padding in GLSL)
// exposure: index 36 (1 float)
// padding after exposure: indices 37-39 (3 floats for padding to make exposure take 16 bytes)
const OFFSET_PROJECTION = 0;
const OFFSET_VIEW = 16; // 16 floats * 4 bytes/float = 64 bytes offset
const OFFSET_CAMERA_POS = 32; // 32 floats * 4 bytes/float = 128 bytes offset
const OFFSET_EXPOSURE = 36; // (32 + 3 floats for vec3 + 1 float for _padding) * 4 bytes/float = 144 bytes offset

cameraMatricesData.set(projectionMatrix, OFFSET_PROJECTION);
cameraMatricesData.set(viewMatrix, OFFSET_VIEW);
cameraMatricesData.set(cameraPos, OFFSET_CAMERA_POS);
cameraMatricesData[OFFSET_EXPOSURE] = exposureValue;

// --------------------------------------------------------------------------------
// Step 3: Bind the UBO to a Binding Point (e.g., binding point 0)
// --------------------------------------------------------------------------------
const UBO_BINDING_POINT = 0; // Choose an available binding point index
gl.bindBufferBase(gl.UNIFORM_BUFFER, UBO_BINDING_POINT, cameraUBO);

// --------------------------------------------------------------------------------
// Step 4: Connect Shader Uniform Block to the Binding Point
// --------------------------------------------------------------------------------
// Get the index of the uniform block 'CameraMatrices' from your shader program
const cameraBlockIndex = gl.getUniformBlockIndex(shaderProgram, 'CameraMatrices');

// Associate the uniform block index with the UBO binding point
gl.uniformBlockBinding(shaderProgram, cameraBlockIndex, UBO_BINDING_POINT);

// Repeat for any other shader programs that use the 'CameraMatrices' uniform block.
// For example, if you had 'anotherShaderProgram':
// const anotherCameraBlockIndex = gl.getUniformBlockIndex(anotherShaderProgram, 'CameraMatrices');
// gl.uniformBlockBinding(anotherShaderProgram, anotherCameraBlockIndex, UBO_BINDING_POINT);

// --------------------------------------------------------------------------------
// Step 5: Update UBO Data (e.g., once per frame, or when camera moves)
// --------------------------------------------------------------------------------
function updateCameraUBO() {
    // Recalculate projection/view if needed
    mat4.perspective(projectionMatrix, Math.PI / 4, gl.canvas.width / gl.canvas.height, 0.1, 100.0);
    // Example: Camera moving around the origin
    const time = performance.now() * 0.001; // Current time in seconds
    const radius = 5;
    const camX = Math.sin(time * 0.5) * radius;
    const camZ = Math.cos(time * 0.5) * radius;
    vec3.set(cameraPos, camX, 2, camZ);
    mat4.lookAt(viewMatrix, cameraPos, vec3.fromValues(0, 0, 0), vec3.fromValues(0, 1, 0));

    // Update the CPU-side Float32Array with new data
    cameraMatricesData.set(projectionMatrix, OFFSET_PROJECTION);
    cameraMatricesData.set(viewMatrix, OFFSET_VIEW);
    cameraMatricesData.set(cameraPos, OFFSET_CAMERA_POS);
    // cameraMatricesData[OFFSET_EXPOSURE] = newExposureValue; // Update if exposure changes

    // Bind the UBO and update its data on the GPU.
    // Using gl.bufferSubData(target, offset, dataView) to update a portion or all of the buffer.
    // Since we're updating the whole array from the start, offset is 0.
    gl.bindBuffer(gl.UNIFORM_BUFFER, cameraUBO);
    gl.bufferSubData(gl.UNIFORM_BUFFER, 0, cameraMatricesData); // Upload the updated data
    gl.bindBuffer(gl.UNIFORM_BUFFER, null); // Unbind to avoid accidental modification
}

// Call updateCameraUBO() before drawing your scene elements each frame.
// For example, within your main render loop:
// requestAnimationFrame(function render(time) {
//    updateCameraUBO();
//    // ... draw your objects ...
//    requestAnimationFrame(render);
// });

            

              
                Copy
              
            
          

Kodo pavyzdys: paprasta transformacijos matricų UBO

Sujunkime viską į išsamesnį, nors ir supaprastintą pavyzdį. Įsivaizduokime, kad atvaizduojame besisukantį kubą ir norime efektyviai valdyti savo kameros matricas naudodami UBO.

Viršūnių šešėliavimo programa (`cube.vert`)

            #version 300 es

layout (location = 0) in vec4 a_position;
layout (location = 1) in vec3 a_normal;

uniform mat4 u_modelMatrix;

layout (std140) uniform CameraMatrices {
    mat4 projection;
    mat4 view;
    vec3 cameraPosition;
    float _padding;
} CameraData;

out vec3 v_normal;
out vec3 v_worldPosition;

void main() {
    vec4 worldPosition = u_modelMatrix * a_position;
    gl_Position = CameraData.projection * CameraData.view * worldPosition;
    v_normal = mat3(u_modelMatrix) * a_normal;
    v_worldPosition = worldPosition.xyz;
}

            

              
                Copy
              
            
          

Fragmentų šešėliavimo programa (`cube.frag`)

            #version 300 es

precision highp float;

in vec3 v_normal;
in vec3 v_worldPosition;

uniform vec3 u_lightDirection;
uniform vec4 u_objectColor;

layout (std140) uniform CameraMatrices {
    mat4 projection;
    mat4 view;
    vec3 cameraPosition;
    float _padding;
} CameraData;

out vec4 outColor;

void main() {
    // Basic diffuse lighting using a standard uniform for light direction
    float diffuse = max(dot(normalize(v_normal), normalize(u_lightDirection)), 0.0);
    
    // Simple specular lighting using camera position from UBO
    vec3 lightDir = normalize(u_lightDirection);
    vec3 norm = normalize(v_normal);
    vec3 viewDir = normalize(CameraData.cameraPosition - v_worldPosition);
    vec3 reflectDir = reflect(-lightDir, norm);
    float spec = pow(max(dot(viewDir, reflectDir), 0.0), 32.0);

    vec4 ambientColor = u_objectColor * 0.1; // Simple ambient
    vec4 diffuseColor = u_objectColor * diffuse;
    vec4 specularColor = vec4(1.0, 1.0, 1.0, 1.0) * spec * 0.5;

    outColor = ambientColor + diffuseColor + specularColor;
}

            

              
                Copy
              
            
          

JavaScript (`main.js`) - Pagrindinė logika

            import { mat4, vec3 } from 'gl-matrix';

// Utility functions for shader compilation (simplified for brevity)
function createShader(gl, type, source) {
    const shader = gl.createShader(type);
    gl.shaderSource(shader, source);
    gl.compileShader(shader);
    if (!gl.getShaderParameter(shader, gl.COMPILE_STATUS)) {
        console.error('Shader compilation error:', gl.getShaderInfoLog(shader));
        gl.deleteShader(shader);
        return null;
    }
    return shader;
}

function createProgram(gl, vertexShaderSource, fragmentShaderSource) {
    const vertexShader = createShader(gl, gl.VERTEX_SHADER, vertexShaderSource);
    const fragmentShader = createShader(gl, gl.FRAGMENT_SHADER, fragmentShaderSource);
    if (!vertexShader || !fragmentShader) return null;

    const program = gl.createProgram();
    gl.attachShader(program, vertexShader);
    gl.attachShader(program, fragmentShader);
    gl.linkProgram(program);
    if (!gl.getProgramParameter(program, gl.LINK_STATUS)) {
        console.error('Shader program linking error:', gl.getProgramInfoLog(program));
        gl.deleteProgram(program);
        return null;
    }
    return program;
}

// Main application logic
async function main() {
    const canvas = document.getElementById('gl-canvas');
    const gl = canvas.getContext('webgl2');

    if (!gl) {
        console.error('WebGL2 not supported on this browser or device.');
        return;
    }

    // Define shader sources inline for the example
    const vertexShaderSource = `
        #version 300 es

        layout (location = 0) in vec4 a_position;
        layout (location = 1) in vec3 a_normal;

        uniform mat4 u_modelMatrix;

        layout (std140) uniform CameraMatrices {
            mat4 projection;
            mat4 view;
            vec3 cameraPosition;
            float _padding;
        } CameraData;

        out vec3 v_normal;
        out vec3 v_worldPosition;

        void main() {
            vec4 worldPosition = u_modelMatrix * a_position;
            gl_Position = CameraData.projection * CameraData.view * worldPosition;
            v_normal = mat3(u_modelMatrix) * a_normal;
            v_worldPosition = worldPosition.xyz;
        }
    `;

    const fragmentShaderSource = `
        #version 300 es

        precision highp float;

        in vec3 v_normal;
        in vec3 v_worldPosition;

        uniform vec3 u_lightDirection;
        uniform vec4 u_objectColor;

        layout (std140) uniform CameraMatrices {
            mat4 projection;
            mat4 view;
            vec3 cameraPosition;
            float _padding;
        } CameraData;

        out vec4 outColor;

        void main() {
            float diffuse = max(dot(normalize(v_normal), normalize(u_lightDirection)), 0.0);
            
            vec3 lightDir = normalize(u_lightDirection);
            vec3 norm = normalize(v_normal);
            vec3 viewDir = normalize(CameraData.cameraPosition - v_worldPosition);
            vec3 reflectDir = reflect(-lightDir, norm);
            float spec = pow(max(dot(viewDir, reflectDir), 0.0), 32.0);

            vec4 ambientColor = u_objectColor * 0.1;
            vec4 diffuseColor = u_objectColor * diffuse;
            vec4 specularColor = vec4(1.0, 1.0, 1.0, 1.0) * spec * 0.5;

            outColor = ambientColor + diffuseColor + specularColor;
        }
    `;

    const shaderProgram = createProgram(gl, vertexShaderSource, fragmentShaderSource);
    if (!shaderProgram) return;

    gl.useProgram(shaderProgram);

    // --------------------------------------------------------------------
    // Setup UBO for Camera Matrices
    // --------------------------------------------------------------------
    const UBO_BINDING_POINT = 0;
    const cameraMatricesUBO = gl.createBuffer();
    gl.bindBuffer(gl.UNIFORM_BUFFER, cameraMatricesUBO);

    // UBO size: (2 * mat4) + (vec3 aligned to 16 bytes) + (float aligned to 16 bytes)
    // = 64 + 64 + 16 + 16 = 160 bytes
    const UBO_BYTE_SIZE = 160;
    gl.bufferData(gl.UNIFORM_BUFFER, UBO_BYTE_SIZE, gl.DYNAMIC_DRAW); // Use DYNAMIC_DRAW for frequent updates
    gl.bindBuffer(gl.UNIFORM_BUFFER, null);

    // Get uniform block index and bind to the global binding point
    const cameraBlockIndex = gl.getUniformBlockIndex(shaderProgram, 'CameraMatrices');
    gl.uniformBlockBinding(shaderProgram, cameraBlockIndex, UBO_BINDING_POINT);

    // CPU-side data storage for matrices and camera position
    const projectionMatrix = mat4.create();
    const viewMatrix = mat4.create();
    const cameraPos = vec3.create(); // This will be updated dynamically

    // Float32Array to hold all UBO data, carefully matching std140 layout
    const cameraMatricesData = new Float32Array(UBO_BYTE_SIZE / Float32Array.BYTES_PER_ELEMENT); // 160 bytes / 4 bytes/float = 40 floats

    // Offsets within the Float32Array (in units of floats)
    const OFFSET_PROJECTION = 0;
    const OFFSET_VIEW = 16; 
    const OFFSET_CAMERA_POS = 32;
    const OFFSET_EXPOSURE = 36; // After 3 floats for vec3 + 1 float padding

    // --------------------------------------------------------------------
    // Setup Cube Geometry (simple, non-indexed cube for demonstration)
    // --------------------------------------------------------------------
    const cubePositions = new Float32Array([
        // Front face
        -1.0, -1.0,  1.0,  1.0, -1.0,  1.0,  1.0,  1.0,  1.0, // Triangle 1
        -1.0, -1.0,  1.0,  1.0,  1.0,  1.0, -1.0,  1.0,  1.0, // Triangle 2
        // Back face
        -1.0, -1.0, -1.0, -1.0,  1.0, -1.0,  1.0,  1.0, -1.0, // Triangle 1
        -1.0, -1.0, -1.0,  1.0,  1.0, -1.0,  1.0, -1.0, -1.0, // Triangle 2
        // Top face
        -1.0,  1.0, -1.0, -1.0,  1.0,  1.0,  1.0,  1.0,  1.0, // Triangle 1
        -1.0,  1.0, -1.0,  1.0,  1.0,  1.0,  1.0,  1.0, -1.0, // Triangle 2
        // Bottom face
        -1.0, -1.0, -1.0,  1.0, -1.0, -1.0,  1.0, -1.0,  1.0, // Triangle 1
        -1.0, -1.0, -1.0,  1.0, -1.0,  1.0, -1.0, -1.0,  1.0, // Triangle 2
        // Right face
         1.0, -1.0, -1.0,  1.0,  1.0, -1.0,  1.0,  1.0,  1.0, // Triangle 1
         1.0, -1.0, -1.0,  1.0,  1.0,  1.0,  1.0, -1.0,  1.0, // Triangle 2
        // Left face
        -1.0, -1.0, -1.0, -1.0, -1.0,  1.0, -1.0,  1.0,  1.0, // Triangle 1
        -1.0, -1.0, -1.0, -1.0,  1.0,  1.0, -1.0,  1.0, -1.0  // Triangle 2
    ]);

    const cubeNormals = new Float32Array([
        // Front
         0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,
        // Back
         0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,
        // Top
         0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,
        // Bottom
         0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,
        // Right
         1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,  1.0,  0.0,  0.0,
        // Left
        -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0, -1.0,  0.0,  0.0
    ]);

    const numVertices = cubePositions.length / 3;

    const positionBuffer = gl.createBuffer();
    gl.bindBuffer(gl.ARRAY_BUFFER, positionBuffer);
    gl.bufferData(gl.ARRAY_BUFFER, cubePositions, gl.STATIC_DRAW);

    const normalBuffer = gl.createBuffer();
    gl.bindBuffer(gl.ARRAY_BUFFER, normalBuffer);
    gl.bufferData(gl.ARRAY_BUFFER, cubeNormals, gl.STATIC_DRAW);

    gl.enableVertexAttribArray(0); // a_position
    gl.bindBuffer(gl.ARRAY_BUFFER, positionBuffer);
    gl.vertexAttribPointer(0, 3, gl.FLOAT, false, 0, 0);

    gl.enableVertexAttribArray(1); // a_normal
    gl.bindBuffer(gl.ARRAY_BUFFER, normalBuffer);
    gl.vertexAttribPointer(1, 3, gl.FLOAT, false, 0, 0);

    // --------------------------------------------------------------------
    // Get locations for standard uniforms (u_modelMatrix, u_lightDirection, u_objectColor)
    // --------------------------------------------------------------------
    const uModelMatrixLoc = gl.getUniformLocation(shaderProgram, 'u_modelMatrix');
    const uLightDirectionLoc = gl.getUniformLocation(shaderProgram, 'u_lightDirection');
    const uObjectColorLoc = gl.getUniformLocation(shaderProgram, 'u_objectColor');

    const modelMatrix = mat4.create();
    const lightDirection = new Float32Array([0.5, 1.0, 0.0]);
    const objectColor = new Float32Array([0.6, 0.8, 1.0, 1.0]);

    // Set static uniforms once (if they don't change)
    gl.uniform3fv(uLightDirectionLoc, lightDirection);
    gl.uniform4fv(uObjectColorLoc, objectColor);

    gl.enable(gl.DEPTH_TEST);

    function updateAndDraw(currentTime) {
        currentTime *= 0.001; // convert to seconds

        // Resize canvas if needed (handles responsive layouts globally)
        if (canvas.width !== canvas.clientWidth || canvas.height !== canvas.clientHeight) {
            canvas.width = canvas.clientWidth;
            canvas.height = canvas.clientHeight;
            gl.viewport(0, 0, canvas.width, canvas.height);
        }

        gl.clearColor(0.1, 0.1, 0.1, 1.0);
        gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT);

        // --- Update Camera UBO data --- 
        // Calculate camera matrices and position
        mat4.perspective(projectionMatrix, Math.PI / 4, canvas.width / canvas.height, 0.1, 100.0);
        const radius = 5;
        const camX = Math.sin(currentTime * 0.5) * radius;
        const camZ = Math.cos(currentTime * 0.5) * radius;
        vec3.set(cameraPos, camX, 2, camZ);
        mat4.lookAt(viewMatrix, cameraPos, vec3.fromValues(0, 0, 0), vec3.fromValues(0, 1, 0));

        // Copy updated data into the CPU-side Float32Array
        cameraMatricesData.set(projectionMatrix, OFFSET_PROJECTION);
        cameraMatricesData.set(viewMatrix, OFFSET_VIEW);
        cameraMatricesData.set(cameraPos, OFFSET_CAMERA_POS);
        // cameraMatricesData[OFFSET_EXPOSURE] is 1.0 (set initially), not changed in loop for simplicity

        // Bind UBO and update its data on GPU (one call for all camera matrices and position)
        gl.bindBuffer(gl.UNIFORM_BUFFER, cameraMatricesUBO);
        gl.bufferSubData(gl.UNIFORM_BUFFER, 0, cameraMatricesData);
        gl.bindBuffer(gl.UNIFORM_BUFFER, null); // Unbind to avoid accidental modification

        // --- Update and set model matrix (standard uniform) for the spinning cube ---
        mat4.identity(modelMatrix);
        mat4.translate(modelMatrix, modelMatrix, [0, 0, 0]);
        mat4.rotateY(modelMatrix, modelMatrix, currentTime);
        mat4.rotateX(modelMatrix, modelMatrix, currentTime * 0.7);

        gl.uniformMatrix4fv(uModelMatrixLoc, false, modelMatrix);

        // Draw the cube
        gl.drawArrays(gl.TRIANGLES, 0, numVertices);

        requestAnimationFrame(updateAndDraw);
    }

    requestAnimationFrame(updateAndDraw);
}

main();

            

              
                Copy
              
            
          

Šis išsamus pavyzdys parodo pagrindinę darbo eigą: sukurkite UBO, skirkite jam vietos (atsižvelgiant į std140), atnaujinkite jį su bufferSubData, kai keičiasi reikšmės, ir prijunkite jį prie savo šešėliavimo programos (-ų) per nuoseklų pririšimo tašką. Svarbiausia išvada yra ta, kad visi su kamera susiję duomenys (projekcija, vaizdas, padėtis) dabar atnaujinami vienu gl.bufferSubData iškvietimu, vietoj kelių individualių gl.uniform... iškvietimų per kadrą. Tai žymiai sumažina API sąnaudas, o tai gali padidinti našumą, ypač jei šios matricos buvo naudojamos daugelyje skirtingų šešėliavimo programų ar daugeliui atvaizdavimo etapų.

Pažangios UBO technikos ir geriausios praktikos

Kai įsisavinsite pagrindus, UBO atvers duris į sudėtingesnius atvaizdavimo modelius ir optimizavimą.

Dinaminiai duomenų atnaujinimai

Duomenims, kurie dažnai keičiasi (pvz., kameros matricos, šviesų padėtys ar animuotos savybės, kurios atnaujinamos kiekvieną kadrą), daugiausia naudosite gl.bufferSubData. Kai iš pradžių skiriate buferį su gl.bufferData, pasirinkite naudojimo užuominą, pvz., gl.DYNAMIC_DRAW arba gl.STREAM_DRAW, kad praneštumėte GPU, jog šio buferio turinys bus dažnai atnaujinamas. Nors gl.DYNAMIC_DRAW yra įprastas numatytasis pasirinkimas duomenims, kurie reguliariai keičiasi, apsvarstykite gl.STREAM_DRAW, jei atnaujinimai yra labai dažni ir duomenys naudojami tik vieną ar kelis kartus prieš juos visiškai pakeičiant, nes tai gali padėti tvarkyklei optimizuoti šį naudojimo atvejį.

Atnaujinant, gl.bufferSubData(target, offset, dataView, srcOffset, length) yra jūsų pagrindinis įrankis. Parametras offset nurodo, kur UBO (baitais) pradėti rašyti dataView (jūsų Float32Array ar panašų). Tai yra labai svarbu, jei atnaujinate tik dalį savo UBO. Pavyzdžiui, jei turite kelias šviesas UBO ir keičiasi tik vienos šviesos savybės, galite atnaujinti tik tos šviesos duomenis, apskaičiuodami jos baitų poslinkį, neįkeliant viso buferio iš naujo. Šis smulkmeniškas valdymas yra galinga optimizavimo priemonė.

Našumo aspektai dažniems atnaujinimams

Net ir su UBO, dažni atnaujinimai vis tiek apima CPU duomenų siuntimą į GPU atmintį, kuri yra ribotas išteklius ir operacija, reikalaujanti sąnaudų. Norėdami optimizuoti dažnus UBO atnaujinimus:

• Atnaujinkite tik tai, kas pasikeitė: Tai yra fundamentalu. Jei pasikeitė tik nedidelė UBO duomenų dalis, naudokite gl.bufferSubData su tiksliu baitų poslinkiu ir mažesniu duomenų vaizdu (pvz., jūsų Float32Array dalimi), kad siųstumėte tik pakeistą dalį. Venkite persiųsti visą buferį, jei tai nėra būtina.
• Dvigubas buferiavimas arba žiediniai buferiai: Itin didelio dažnio atnaujinimams, pavyzdžiui, animuojant šimtus objektų ar sudėtingas dalelių sistemas, kur kiekvieno kadro duomenys yra skirtingi, apsvarstykite galimybę skirti kelis UBO. Galite cikliškai naudoti šiuos UBO (žiedinio buferio metodas), leisdami CPU rašyti į vieną buferį, kol GPU vis dar skaito iš kito. Tai gali užkirsti kelią CPU laukimui, kol GPU baigs skaityti iš buferio, į kurį CPU bando rašyti, sumažinant konvejerio strigimus ir gerinant CPU-GPU paralelumą. Tai yra pažangesnė technika, tačiau gali duoti reikšmingų rezultatų labai dinamiškose scenose.
• Duomenų pakavimas: Kaip visada, užtikrinkite, kad jūsų CPU pusės duomenų masyvas būtų glaudžiai supakuotas (laikantis std140 taisyklių), kad išvengtumėte nereikalingų atminties skyrimų ir kopijavimo. Mažesni duomenys reiškia trumpesnį perdavimo laiką.

Keli uniformų blokai

Jūs neapsiribojate vienu uniform bloku vienai šešėliavimo programai ar net vienai programai. Sudėtinga 3D scena ar variklis beveik neabejotinai gaus naudos iš kelių, logiškai atskirtų UBO:

• CameraMatrices UBO: Projekcijai, vaizdui, atvirkštiniam vaizdui ir kameros pasaulio pozicijai. Tai yra globalu scenai ir keičiasi tik tada, kai kamera juda.
• LightInfo UBO: Aktyvių šviesų masyvui, jų pozicijoms, kryptims, spalvoms, tipams ir slopinimo parametrams. Tai gali keistis, kai pridedamos, pašalinamos ar animuojamos šviesos.
• MaterialProperties UBO: Bendrai medžiagų parametrams, tokiems kaip blizgumas, atspindėjimas, PBR parametrai (šiurkštumas, metališkumas) ir t. t., kurie gali būti bendrinami tarp objektų grupių arba indeksuojami pagal medžiagą.
• SceneGlobals UBO: Globaliam laikui, rūko parametrams, aplinkos žemėlapio intensyvumui, globaliai aplinkos spalvai ir t. t.
• AnimationData UBO: Skeletinės animacijos duomenims (sąnarių matricoms), kurie gali būti bendrinami tarp kelių animuotų personažų, naudojančių tą pačią įrangą.

Kiekvienas atskiras uniform blokas turėtų savo pririšimo tašką ir su juo susijusį UBO. Šis modulinis požiūris daro jūsų šešėliavimo programos kodą švaresnį, jūsų duomenų valdymą organizuotesnį ir leidžia geriau naudoti spartinančiąją atmintį (cache) GPU. Štai kaip tai galėtų atrodyti šešėliavimo programoje:

            #version 300 es

// ... attributes ...

layout (std140) uniform CameraMatrices { /* ... camera uniforms ... */ } CameraData;
layout (std140) uniform LightInfo {
    vec3 positions[MAX_LIGHTS];
    vec4 colors[MAX_LIGHTS];
    // ... other light properties ...
} SceneLights;
layout (std140) uniform Material {
    vec4 albedoColor;
    float metallic;
    float roughness;
    // ... other material properties ...
} ObjectMaterial;

// ... other uniforms and outputs ...

            

              
                Copy
              
            
          

JavaScript'e tada gautumėte bloko indeksą kiekvienam uniform blokui (pvz., 'LightInfo', 'Material') ir pririštumėte juos prie skirtingų, unikalių pririšimo taškų (pvz., 1, 2):

            
// For LightInfo UBO
const LIGHT_UBO_BINDING_POINT = 1;
const lightInfoUBO = gl.createBuffer();
gl.bindBuffer(gl.UNIFORM_BUFFER, lightInfoUBO);
gl.bufferData(gl.UNIFORM_BUFFER, LIGHT_UBO_BYTE_SIZE, gl.DYNAMIC_DRAW); // Size calculated based on lights array
gl.bindBuffer(gl.UNIFORM_BUFFER, null);

const lightBlockIndex = gl.getUniformBlockIndex(shaderProgram, 'LightInfo');
gl.uniformBlockBinding(shaderProgram, lightBlockIndex, LIGHT_UBO_BINDING_POINT);

// For Material UBO
const MATERIAL_UBO_BINDING_POINT = 2;
const materialUBO = gl.createBuffer();
gl.bindBuffer(gl.UNIFORM_BUFFER, materialUBO);
gl.bufferData(gl.UNIFORM_BUFFER, MATERIAL_UBO_BYTE_SIZE, gl.STATIC_DRAW); // Material might be static per object
gl.bindBuffer(gl.UNIFORM_BUFFER, null);

const materialBlockIndex = gl.getUniformBlockIndex(shaderProgram, 'Material');
gl.uniformBlockBinding(shaderProgram, materialBlockIndex, MATERIAL_UBO_BINDING_POINT);

// ... then update lightInfoUBO and materialUBO with gl.bufferSubData as needed ...

            

              
                Copy
              
            
          

UBO bendrinimas tarp programų

Viena galingiausių ir efektyvumą didinančių UBO savybių yra jų galimybė būti lengvai bendrinamiems. Įsivaizduokite, kad turite šešėliavimo programą nepermatomiems objektams, kitą – permatomiems objektams, ir trečią – post-apdorojimo efektams. Visoms trims gali prireikti tų pačių kameros matricų. Su UBO, jūs sukuriate *vieną* cameraMatricesUBO, atnaujinate jo duomenis vieną kartą per kadrą (naudodami gl.bufferSubData), o tada pririšate jį prie to paties pririšimo taško (pvz., 0) *visoms* susijusioms šešėliavimo programoms. Kiekviena programa turėtų savo CameraMatrices uniform bloką, susietą su pririšimo tašku 0.

Tai drastiškai sumažina perteklinį duomenų perdavimą per CPU-GPU magistralę ir užtikrina, kad visos šešėliavimo programos veiktų su lygiai ta pačia naujausia kameros informacija. Tai yra labai svarbu vizualiniam nuoseklumui, ypač sudėtingose scenose su keliais atvaizdavimo etapais ar skirtingų tipų medžiagomis.

            
// Assume shaderProgramOpaque, shaderProgramTransparent, shaderProgramPostProcess are linked

const UBO_BINDING_POINT_CAMERA = 0; // The chosen binding point for camera data

// Bind the camera UBO to this binding point for the opaque shader
const opaqueCameraBlockIndex = gl.getUniformBlockIndex(shaderProgramOpaque, 'CameraMatrices');
gl.uniformBlockBinding(shaderProgramOpaque, opaqueCameraBlockIndex, UBO_BINDING_POINT_CAMERA);

// Bind the same camera UBO to the same binding point for the transparent shader
const transparentCameraBlockIndex = gl.getUniformBlockIndex(shaderProgramTransparent, 'CameraMatrices');
gl.uniformBlockBinding(shaderProgramTransparent, transparentCameraBlockIndex, UBO_BINDING_POINT_CAMERA);

// And for the post-processing shader
const postProcessCameraBlockIndex = gl.getUniformBlockIndex(shaderProgramPostProcess, 'CameraMatrices');
gl.uniformBlockBinding(shaderProgramPostProcess, postProcessCameraBlockIndex, UBO_BINDING_POINT_CAMERA);

// The cameraMatricesUBO is then updated once per frame, and all three shaders automatically access the latest data.

            

              
                Copy
              
            
          

UBO pavyzdžių atvaizdavimui (Instanced Rendering)

Nors UBO pirmiausia skirti uniform duomenims, jie atlieka galingą pagalbinį vaidmenį pavyzdžių atvaizdavime, ypač derinant su WebGL2 gl.drawArraysInstanced ar gl.drawElementsInstanced. Labai dideliam pavyzdžių skaičiui, pavyzdžio duomenys paprastai geriausiai tvarkomi per atributų buferio objektą (ABO) su gl.vertexAttribDivisor.

Tačiau, UBO gali efektyviai saugoti duomenų masyvus, kurie pasiekiami pagal indeksą šešėliavimo programoje, tarnaujantys kaip paieškos lentelės pavyzdžių savybėms, ypač jei pavyzdžių skaičius neviršija UBO dydžio apribojimų. Pavyzdžiui, mat4 masyvas modelio matricoms mažam ar vidutiniam pavyzdžių skaičiui galėtų būti saugomas UBO. Kiekvienas pavyzdys tada naudoja įmontuotą gl_InstanceID šešėliavimo programos kintamąjį, kad pasiektų savo konkrečią matricą iš masyvo UBO viduje. Šis modelis yra retesnis nei ABO pavyzdžių specifiniams duomenims, bet yra gyvybinga alternatyva tam tikriems scenarijams, pavyzdžiui, kai pavyzdžio duomenys yra sudėtingesni (pvz., visa struktūra vienam pavyzdžiui) arba kai pavyzdžių skaičius yra valdomas UBO dydžio apribojimuose.

            
#version 300 es

// ... other attributes and uniforms ...

layout (std140) uniform InstanceData {
    mat4 instanceModelMatrices[MAX_INSTANCES]; // Array of model matrices
    vec4 instanceColors[MAX_INSTANCES];         // Array of colors
} InstanceTransforms;

void main() {
    // Access instance-specific data using gl_InstanceID
    mat4 modelMatrix = InstanceTransforms.instanceModelMatrices[gl_InstanceID];
    vec4 instanceColor = InstanceTransforms.instanceColors[gl_InstanceID];

    gl_Position = CameraData.projection * CameraData.view * modelMatrix * a_position;
    // ... apply instanceColor to final output ...
}

            

              
                Copy
              
            
          

Nepamirškite, kad `MAX_INSTANCES` turi būti kompiliavimo laiko konstanta (const int arba preprocesoriaus direktyva) šešėliavimo programoje, o bendras UBO dydis yra apribotas gl.MAX_UNIFORM_BLOCK_SIZE (kurį galima užklausti vykdymo metu, dažnai 16KB-64KB diapazone modernioje aparatinėje įrangoje).

UBO derinimas

UBO derinimas gali būti sudėtingas dėl netiesioginio duomenų pakavimo pobūdžio ir fakto, kad duomenys yra GPU. Jei jūsų atvaizdavimas atrodo neteisingai arba duomenys atrodo sugadinti, apsvarstykite šiuos derinimo veiksmus:

• Kruopščiai patikrinkite std140 išdėstymą: Tai yra pats dažniausias klaidų šaltinis. Dukart patikrinkite savo JavaScript Float32Array poslinkius, dydžius ir užpildymą pagal std140 taisykles *kiekvienam* nariui. Nupieškite savo atminties išdėstymo diagramas, aiškiai pažymėdami baitus. Net vieno baito išlygiavimo neatitikimas gali sugadinti vėlesnius duomenis.
• Patikrinkite gl.getUniformBlockIndex: Įsitikinkite, kad uniform bloko pavadinimas, kurį perduodate (pvz., 'CameraMatrices'), *tiksliai* atitinka (atsižvelgiant į didžiąsias ir mažąsias raides) tarp jūsų šešėliavimo programos ir jūsų JavaScript kodo.
• Patikrinkite gl.uniformBlockBinding: Įsitikinkite, kad JavaScript'e nurodytas pririšimo taškas (pvz., 0) atitinka pririšimo tašką, kurį ketinate naudoti šešėliavimo programos blokui.
• Patvirtinkite gl.bufferSubData/gl.bufferData naudojimą: Patikrinkite, ar jūs iš tikrųjų iškviečiate gl.bufferSubData (arba gl.bufferData), kad perduotumėte *naujausius* CPU pusės duomenis į GPU buferį. To pamiršimas paliks pasenusius duomenis GPU.
• Naudokite WebGL inspektoriaus įrankius: Naršyklės kūrėjo įrankiai (pvz., Spector.js, arba naršyklėje įmontuoti WebGL derintuvai) yra neįkainojami. Jie dažnai gali parodyti jūsų UBO turinį tiesiogiai GPU, padėdami patikrinti, ar duomenys buvo įkelti teisingai ir ką šešėliavimo programa iš tikrųjų skaito. Jie taip pat gali pabrėžti API klaidas ar įspėjimus.
• Nuskaitykite duomenis atgal (tik derinimui): Kūrimo metu galite laikinai nuskaityti UBO duomenis atgal į CPU naudodami gl.getBufferSubData(target, srcByteOffset, dstBuffer, dstOffset, length), kad patikrintumėte jų turinį. Ši operacija yra labai lėta ir sukelia konvejerio sustojimą, todėl jos *niekada* negalima daryti produkcijos kode.
• Supaprastinkite ir izoliuokite: Jei sudėtingas UBO neveikia, supaprastinkite jį. Pradėkite nuo UBO, kuriame yra vienas float ar vec4, pasiekite, kad jis veiktų, ir palaipsniui pridėkite sudėtingumo (vec3, masyvai, struktūros), tikrindami kiekvieną papildymą.

Našumo aspektai ir optimizavimo strategijos

Nors UBO siūlo reikšmingų našumo pranašumų, jų optimalus naudojimas reikalauja kruopštaus apsvarstymo ir pagrindinės aparatinės įrangos pasekmių supratimo.

Atminties valdymas ir duomenų išdėstymas

• Glaudus pakavimas atsižvelgiant į `std140`: Visada stenkitės kuo glaudžiau supakuoti savo CPU pusės duomenis, griežtai laikydamiesi std140 taisyklių. Tai sumažina perduodamų ir saugomų duomenų kiekį. Nereikalingas užpildymas CPU pusėje švaisto atmintį ir pralaidumą. Įrankiai, kurie apskaičiuoja std140 poslinkius, čia gali būti tikras išsigelbėjimas.
• Venkite perteklinių duomenų: Nedėkite duomenų į UBO, jei jie yra tikrai pastovūs per visą jūsų programos gyvavimo laiką ir visoms šešėliavimo programoms; tokiais atvejais pakanka paprasto standartinio uniform kintamojo, nustatyto vieną kartą. Panašiai, jei duomenys yra griežtai skirti kiekvienai viršūnei, jie turėtų būti atributas, o ne uniform.
• Skirkite su teisingomis naudojimo užuominomis: Naudokite gl.STATIC_DRAW UBO, kurie retai arba niekada nesikeičia (pvz., statiniai scenos parametrai). Naudokite gl.DYNAMIC_DRAW tiems, kurie dažnai keičiasi (pvz., kameros matricos, animuotos šviesų padėtys). Ir apsvarstykite gl.STREAM_DRAW duomenims, kurie keičiasi beveik kiekvieną kadrą ir yra naudojami tik vieną kartą (pvz., tam tikri dalelių sistemos duomenys, kurie yra visiškai iš naujo generuojami kiekvieną kadrą). Šios užuominos padeda GPU tvarkyklei geriausiai optimizuoti atminties skyrimą ir spartinančiąją atmintį.

Piešimo iškvietimų grupavimas su UBO

UBO ypač pasižymi, kai reikia atvaizduoti daug objektų, kurie dalijasi ta pačia šešėliavimo programa, bet turi skirtingas uniform savybes (pvz., skirtingas modelio matricas, spalvas ar medžiagų ID). Vietoj brangios operacijos atnaujinti individualius uniform kintamuosius ir iškviesti naują piešimo iškvietimą kiekvienam objektui, galite pasinaudoti UBO, kad pagerintumėte grupavimą:

1. Grupuokite panašius objektus: Organizuokite savo scenos grafiką taip, kad sugrupuotumėte objektus, kurie gali dalytis ta pačia šešėliavimo programa ir UBO (pvz., visi nepermatomi objektai, naudojantys tą patį apšvietimo modelį).
2. Saugokite objekto duomenis: Tokios grupės objektų unikalūs uniform duomenys (pvz., jų modelio matrica ar medžiagos indeksas) gali būti efektyviai saugomi. Labai daugeliui pavyzdžių tai dažnai reiškia pavyzdžio duomenų saugojimą atributų buferio objekte (ABO) ir pavyzdžių atvaizdavimo naudojimą (gl.drawArraysInstanced arba gl.drawElementsInstanced). Tada šešėliavimo programa naudoja gl_InstanceID, kad surastų teisingą modelio matricą ar kitas savybes iš ABO.
3. UBO kaip paieškos lentelės (mažesniam pavyzdžių skaičiui): Mažesniam pavyzdžių skaičiui, UBO gali iš tikrųjų laikyti struktūrų masyvus, kur kiekviena struktūra apima vieno objekto savybes. Šešėliavimo programa vis tiek naudotų gl_InstanceID, kad pasiektų savo specifinius duomenis (pvz., InstanceData.modelMatrices[gl_InstanceID]). Tai leidžia išvengti atributų daliklių sudėtingumo, jei taikoma.

Šis metodas žymiai sumažina API iškvietimų sąnaudas, leisdamas GPU apdoroti daug pavyzdžių lygiagrečiai vienu piešimo iškvietimu, dramatiškai padidinant našumą, ypač scenose su dideliu objektų skaičiumi.

Venkite dažnų buferio atnaujinimų

Net vienas gl.bufferSubData iškvietimas, nors ir efektyvesnis už daugelį individualių uniform iškvietimų, nėra nemokamas. Jis apima atminties perdavimą ir gali sukelti sinchronizacijos taškus. Duomenims, kurie keičiasi retai arba nuspėjamai:

• Minimizuokite atnaujinimus: Atnaujinkite UBO tik tada, kai jo pagrindiniai duomenys iš tikrųjų pasikeičia. Jei jūsų kamera yra statinė, atnaujinkite jos UBO vieną kartą. Jei šviesos šaltinis nejuda, atnaujinkite jo UBO tik tada, kai pasikeičia jo spalva ar intensyvumas.
• Daliniai vs. pilni duomenys: Jei keičiasi tik maža didelio UBO dalis (pvz., viena šviesa dešimties šviesų masyve), naudokite gl.bufferSubData su tiksliu baitų poslinkiu ir mažesniu duomenų vaizdu, apimančiu tik pakeistą dalį, vietoj to, kad iš naujo įkeltumėte visą UBO. Tai sumažina perduodamų duomenų kiekį.
• Nekintami duomenys: Tikrai statiniams uniform kintamiesiems, kurie niekada nesikeičia, nustatykite juos vieną kartą su gl.bufferData(..., gl.STATIC_DRAW), ir tada niekada nekvieskite jokių atnaujinimo funkcijų tam UBO. Tai leidžia GPU tvarkyklei patalpinti duomenis optimalioje, tik skaitymui skirtoje atmintyje.

Testavimas ir profiliavimas

Kaip ir su bet kokiu optimizavimu, visada profiliuokite savo programą. Nemanykite, kur yra butelio kakleliai; išmatuokite juos. Įrankiai, tokie kaip naršyklės našumo monitoriai (pvz., Chrome DevTools, Firefox Developer Tools), Spector.js ar kiti WebGL derintuvai, gali padėti identifikuoti butelio kaklelius. Išmatuokite laiką, praleistą CPU-GPU perdavimams, piešimo iškvietimams, šešėliavimo programų vykdymui ir bendrą kadro laiką. Ieškokite ilgų kadrų, CPU naudojimo šuolių, susijusių su WebGL iškvietimais, ar per didelio GPU atminties naudojimo. Šie empiriniai duomenys padės jūsų UBO optimizavimo pastangoms, užtikrinant, kad sprendžiate realius, o ne tariamus butelio kaklelius. Globalūs našumo aspektai reiškia, kad profiliavimas įvairiuose įrenginiuose ir tinklo sąlygose yra labai svarbus.

Dažnos klaidos ir kaip jų išvengti

Net patyrę kūrėjai gali patekti į spąstus dirbdami su UBO. Štai keletas dažnų problemų ir strategijų, kaip jų išvengti:

Neatitinkantys duomenų išdėstymai

Tai yra pati dažniausia ir labiausiai varginanti problema. Jei jūsų JavaScript Float32Array (ar kitas tipizuotas masyvas) visiškai neatitinka jūsų GLSL uniform bloko std140 taisyklių, jūsų šešėliavimo programos skaitys šiukšles. Tai gali pasireikšti kaip neteisingos transformacijos, keistos spalvos ar net strigimai.

• Dažnų klaidų pavyzdžiai:
  • Neteisingas vec3 užpildymas: Pamiršimas, kad vec3 yra išlygiuoti 16 baitų std140, nors jie užima tik 12 baitų.
  • Masyvo elementų išlygiavimas: Nesupratimas, kad kiekvienas masyvo elementas (net pavieniai float'ai ar int'ai) UBO viduje yra išlygiuotas 16 baitų riboje.
  • Struktūros išlygiavimas: Neteisingas užpildymo, reikalingo tarp struktūros narių, arba bendro struktūros dydžio, kuris taip pat turi būti 16 baitų kartotinis, apskaičiavimas.

Išvengimas: Visada naudokite vizualinę atminties išdėstymo diagramą arba pagalbinę biblioteką, kuri apskaičiuoja std140 poslinkius už jus. Rankiniu būdu kruopščiai apskaičiuokite poslinkius derinimui, atsižvelgdami į baitų poslinkius ir kiekvieno elemento reikalaujamą išlygiavimą. Būkite ypač kruopštūs.

Neteisingi pririšimo taškai

Jei pririšimo taškas, kurį nustatėte su gl.bindBufferBase ar gl.bindBufferRange JavaScript'e, neatitinka pririšimo taško, kurį aiškiai (arba netiesiogiai, jei nenurodyta šešėliavimo programoje) priskyrėte uniform blokui naudodami gl.uniformBlockBinding, jūsų šešėliavimo programa neras duomenų.

Išvengimas: Apibrėžkite nuoseklią pavadinimų suteikimo konvenciją arba naudokite JavaScript konstantas savo pririšimo taškams. Nuosekliai patikrinkite šias reikšmes visame savo JavaScript kode ir konceptualiai su savo šešėliavimo programų deklaracijomis. Derinimo įrankiai dažnai gali patikrinti aktyvius uniform buferio pririšimus.

Pamiršimas atnaujinti buferio duomenis

Jei jūsų CPU pusės uniform reikšmės pasikeičia (pvz., atnaujinama matrica), bet pamirštate iškviesti gl.bufferSubData (arba gl.bufferData), kad perkeltumėte naujas reikšmes į GPU buferį, jūsų šešėliavimo programos ir toliau naudos pasenusius duomenis iš ankstesnio kadro ar pradinio įkėlimo.

Išvengimas: Inkapsuliuokite savo UBO atnaujinimus į aiškią funkciją (pvz., updateCameraUBO()), kuri yra iškviečiama tinkamu laiku jūsų atvaizdavimo cikle (pvz., vieną kartą per kadrą arba esant konkrečiam įvykiui, pvz., kameros judėjimui). Užtikrinkite, kad ši funkcija aiškiai pririša UBO ir iškviečia teisingą buferio duomenų atnaujinimo metodą.

WebGL konteksto praradimo tvarkymas

Kaip ir visi WebGL ištekliai (tekstūros, buferiai, šešėliavimo programos), UBO turi būti atkurti, jei prarandamas WebGL kontekstas (pvz., dėl naršyklės skirtuko strigimo, GPU tvarkyklės perkrovimo ar išteklių išnaudojimo). Jūsų programa turėtų būti pakankamai tvirta, kad su tuo susidorotų, klausydamasi webglcontextlost ir webglcontextrestored įvykių ir iš naujo inicializuodama visus GPU pusės išteklius, įskaitant UBO, jų duomenis ir jų pririšimus.

Išvengimas: Įgyvendinkite tinkamą konteksto praradimo ir atkūrimo logiką visiems WebGL objektams. Tai yra labai svarbus aspektas kuriant patikimas WebGL programas pasauliniam diegimui.

WebGL duomenų perdavimo ateitis: už UBO ribų

Nors UBO yra efektyvaus duomenų perdavimo WebGL2 pagrindas, grafikos API peizažas nuolat kinta. Technologijos, tokios kaip WebGPU, WebGL įpėdinis, pristato dar tiesioginius ir lankstesnius būdus valdyti GPU išteklius ir duomenis. WebGPU aiškus pririšimo modelis, skaičiavimo šešėliavimo programos ir modernesnis buferių valdymas (pvz., saugojimo buferiai, atskiri skaitymo/rašymo prieigos modeliai) siūlo dar smulkesnį valdymą ir siekia dar labiau sumažinti tvarkyklės sąnaudas, o tai lemia didesnį našumą ir nuspėjamumą, ypač labai lygiagrečiose GPU darbo krūviuose.

Tačiau WebGL2 ir UBO išliks labai aktualūs artimiausioje ateityje, ypač atsižvelgiant į platų WebGL suderinamumą tarp įrenginių ir naršyklių visame pasaulyje. UBO įvaldymas šiandien suteikia jums pagrindines žinias apie GPU pusės duomenų valdymą ir atminties išdėstymus, kurios puikiai pasitarnaus ateities grafikos API ir padarys perėjimą prie WebGPU daug sklandesnį.

Išvada: suteikite galių savo WebGL programoms

Uniformų buferio objektai yra nepakeičiamas įrankis bet kurio rimto WebGL2 kūrėjo arsenale. Suprasdami ir teisingai įgyvendindami UBO, galite:

• Žymiai sumažinti CPU-GPU komunikacijos sąnaudas, o tai lemia didesnį kadrų dažnį ir sklandesnes sąveikas.
• Pagerinti sudėtingų scenų našumą, ypač tų, kuriose yra daug objektų, dinaminių duomenų ar keli atvaizdavimo etapai.
• Supaprastinti šešėliavimo programų duomenų valdymą, padarant jūsų WebGL programos kodą švaresnį, moduliaresnį ir lengviau prižiūrimą.
• Atrasti pažangias atvaizdavimo technikas, tokias kaip efektyvus pavyzdžių atvaizdavimas, bendrinami uniform rinkiniai tarp skirtingų šešėliavimo programų ir sudėtingesni apšvietimo ar medžiagų modeliai.

Nors pradinė sąranka reikalauja statesnės mokymosi kreivės, ypač dėl tikslių std140 išdėstymo taisyklių, našumo, mastelio ir kodo organizavimo nauda yra verta investicijų. Toliau kuriant sudėtingas 3D programas pasaulinei auditorijai, UBO bus pagrindinis įrankis, leidžiantis teikti sklandžias, aukštos kokybės patirtis įvairioje interneto įrenginių ekosistemoje.

Priimkite UBO ir pakelkite savo WebGL našumą į kitą lygį!

Tolimesniam skaitymui ir ištekliai

• MDN Web Docs: WebGL uniform attributes - Geras pradžios taškas WebGL pagrindams.
• OpenGL Wiki: Uniform Buffer Object - Išsami UBO specifikacija OpenGL.
• LearnOpenGL: Advanced GLSL (Uniform Buffer Objects section) - Labai rekomenduojamas išteklius GLSL ir UBO supratimui.
• WebGL2 Fundamentals: Uniform Buffers - Praktiški WebGL2 pavyzdžiai ir paaiškinimai.
• gl-matrix library for JavaScript vector/matrix math - Būtina efektyvioms matematikos operacijoms WebGL.
• Spector.js - Galingas WebGL derinimo plėtinys.